Data storage technology over the years has evolved from a direct attached storage model (DAS) to using remote computer storage models, such as Network Attached Storage (NAS) and Storage Area Network (SAN). With the direct storage model, the storage is directly attached to the workstations and applications servers, but this creates numerous difficulties with administration, backup, compliance, and maintenance of the directly stored data. These difficulties are alleviated at least in part by separating the application server/workstations form the storage medium, for example, using a computer storage network.
These computer storage networks may be configured as high-availability clusters (also known as HA clusters or failover clusters), which are groups of computers that support server applications that can be reliably utilized with a minimum of down-time. They operate by harnessing redundant computers in groups or clusters that provide continued service when system components fail. Without clustering, if a server running a particular application crashes, the application will be unavailable until the crashed server is fixed. HA clustering remedies this situation by detecting hardware/software faults, and immediately restarting the application on another system without requiring administrative intervention, a process known as failover. As part of this process, clustering software may configure the node before starting the application on it. For example, appropriate file systems may need to be imported and mounted, network hardware may have to be configured, and some supporting applications may need to be running as well.
HA clusters are often used for critical databases, file sharing on a network, business applications, and customer services such as electronic commerce websites. HA cluster implementations attempt to build redundancy into a cluster to eliminate single points of failure, including multiple network connections and data storage which is redundantly connected via storage area networks.
In order to provide higher performance in data storage systems connected via storage area networks, write-back caching is used for transferring data from an initiator device to a target device. Write-back caching refers to a method of executing write requests where a host computer transfers write request data to a caching disk array controller, or storage processor (SP), which then transfers the write request data to storage media. Depending upon the particular write-back caching strategy being implemented by the controller, the write request data can either be written immediately to the storage media, or the write request data can be temporarily stored in a cache memory as unwritten or “dirty data” and then “flushed” or written to the storage media at some later point in time. In both cases, the controller sends back status information to the host computer indicating that the write request is complete so that the host computer can continue executing a software application. What is meant herein by the use of the term “dirty data” is data that is located in cache memory which has not yet been written to storage media. The term “flush,” (or variants such as “flushed,” or “flushing”) in context of cache and storage means the act of writing dirty data to storage media.
In bursty host computer environments, such as when the host computer intermittently has a large number of write requests, write-back caching permits the host computer to quickly transfer all of the write request data to cache memory thus increasing the performance of the host computer by reducing the host computer's overhead in executing the large number of write requests. The increased performance of the host computer when utilizing write-back caching is accompanied by an increased risk of data loss in the event of a controller failure or the like which may occur subsequent to sending the host computer status information but prior to actually writing the data to storage media.
Intermediate levels of write request data protection have been developed which involve the use of controller pairs that mirror the write request data for redundancy purposes prior to sending status to the host computer. When using two controllers to mirror write request data, a primary controller receives a write request from a host computer. The primary controller then instructs its pair or partner controller to store a copy of the write request data into a cache memory area of the partner controller for redundancy purposes before the primary controller sends status information to the host computer and before the primary controller places the data on the storage media.
The host computer system has a number of configuration options available for dealing with the problem of one controller failing or being otherwise unreachable by the host. In an active/passive array, a logical unit number (LUN) is “owned” by a primary controller. In the case of primary controller failure, the non-owning standby controller switches from standby to active and takes ownership of the LUN so that I/O can continue as normal. In a symmetric active/active array, also called dual active, both controllers are active simultaneously and either may be used to access the LUN. However, the dual active configuration requires complex locking mechanisms and a supporting infrastructure to ensure data integrity across controllers.
With an asymmetric active/active configuration, also known as asymmetric logic unit access or ALUA, the LUN is reachable across both controllers at the same time. However, only one of these controllers “owns” the LUN and because of that, there will be optimized and unoptimized paths. The optimized paths are the ones with a direct path to controller that owns the LUN. The unoptimized paths have a connection with the controller that does not own the LUN and an indirect path to the controller that does own it via an interconnect channel. Paths for the “non-owning” controller take I/O and send it across this interconnect and advertise themselves as “active (non-optimized).” Despite both controllers being active simultaneously, data reads intended for a LUN sent to the non-owning controller in an ALUA environment have a large performance cost since they must be routed through the owning controller. This can be a significant drain on overall system performance.